feat: add official GitHub Action for CI/CD translation automation - #2

I found a few blocking issues in the composite action behavior that should be fixed before merging.

1. The install step mutates the consumer repository. npm install -D solid-translate, bun add -d solid-translate, pnpm add -D solid-translate, and yarn add -D solid-translate all update package manifests and lockfiles. The later change detector treats any changed JSON file as translation output, so a first run can report changed=true just because package.json changed, and commit: true can commit dependency installation changes back to the user's repo. An action should avoid persistent dependency mutation, for example by running the packaged CLI via the action checkout or by using a non-mutating package execution path.

2. The change detection/output scope is too broad and too narrow at the same time. It flags every changed JSON file, including package.json, unrelated config, or app data, but misses .solid-translate.lock when it is the only changed file and misses the Markdown/MDX paths that the README says the CLI supports. That makes changed and files unreliable and can skip commits that should happen.

3. User-controlled inputs are interpolated directly into shell scripts. In particular commit-message is expanded inside git commit -m "...", and package-manager is expanded inside the shell case. GitHub evaluates those expressions before bash runs, so quotes or command substitutions in inputs can alter the script. Please pass inputs through environment variables and quote the shell variables, and validate enum-like inputs explicitly.

4. The README example combines pull_request, contents: write, and commit: true, but the action commits and runs plain git push. With actions/checkout defaults on PR events this is often a detached merge ref or read-only token path, especially for forks, so the documented workflow is likely to fail or behave inconsistently. The docs should either show a push-only auto-commit flow or a PR-safe pattern with an explicit checkout ref/PR creation step.

CI is green, and the committed bun.lock looks consistent with the current Bun-based CI. These action-level issues are enough that I would not merge this version yet.